Database systems are quite prevalent in today's world. Databases store large quantities of information in such a manner so as to facilitate expeditious querying and ease of use. For example, in a conventional relational database, information can be organized as objects such as records, tables and indexes. Database engines provide a mechanism to retrieve and manipulate data from database tables upon specification of a query by a user. A query is typically expressed in some query language such as Structured Query Language (SQL). A query can specify one or more tables as well as rows and columns therein to be retrieved and otherwise manipulated. Upon proper specification of a query, the database engine retrieves data, performs any specified operations and produces a results table. Databases are popular and useful at least in part because of their ability to store large amounts of data, which can be efficiently retrieved and manipulated by simply specifying a query.
Unfortunately, user errors are a common problem in database systems. Usually, such errors occur when a database application or a user changes or deletes data by mistake and the database system correctly follows the command and promptly changes or deletes data. This is referred to in the art as the quick finger delete problem. For example, a user could issue a command to delete a table and forget to specify the “WHERE” clause causing more data to be deleted than intended. Additionally, a user may install a new application that modifies a database in a manner unbeknownst to the user. There are several conventional solutions to this problem. Generally, the most common solution is a full database restore to a point in time prior to the occurrence of a user error. Once restored, the database can be brought online and all changes, including the user error, are lost. However, a full database restore is time intensive sometimes taking days to complete.
Alternatively, data that was unintentionally modified can be remedied by extracting relevant information from a restore database and merging it back into the original database. A variation on this scheme is called log shipping.
Log shipping involves keeping a coping of the database on another secondary server in a restore state, but at a constant delay behind the original server. Log backups are applied to the secondary database only after a delay (e.g., 24 hours). If a user error occurs on an original database, and a database administrator notices the error within the delay, then the database administrator can revert to the secondary server because it already contains the database at a point in time prior to the error. Unfortunately, log shipping is complex requires many additional resources and space.
Restoring a database utilizing conventional systems and methodologies requires sizeable delays and therefore is generally an option of last resort. Furthermore, log shipping requires additional hardware and adds complexity to the database system. Mitigating errors is a large and important problem in database systems. Accordingly, there is a need in the art for a new system and method of restoring databases that is, among other things, both quick and simple.